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INTERVIEW AGENDA - (Informal - Do not enter) 

Attached is an Interview Agenda for the telephone interview that has been scheduled for 
Tuesday, November 1 8, 2008, concerning the above-referenced application, between Examiner 
Thuy Chan Dao and Mark W. Wilson, representing the applicants, at 1 :30 p.m. EST (10:30 p.m. 
PST). 

Applicants thank the Examiner in advance for the courtesy of the scheduled interview. 
I, Claim 1 

A. Claim 1 recites: 

A method of type-checking a code segment written in a programming 
language comprising: 

translating the code segment from the programming language to one or 
more representations of an intermediate language, wherein the one or more 
representations of the intermediate language are capable of representing programs 
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written in a plurality of different source languages, wherein the plurality of 
different source languages comprise at least one typed source language and at 
least one untyped source language; and 

type-checking the one or more representations based on a rule set, wherein 
the rule set comprises rules for type-checking a type designated as an unknown 
type, wherein the unknown type indicates that an element of the representation is 
of a type that is not known. 

B. Lidin, Inside Microsoft ,NETIL Assembler ("IL Assembler") 

IL Assembler's description at pages 9 through 12 does not describe "a type designated as 
an unknown type, wherein the unknown type indicates that an element of the representation is of 
a type that is not known" as stated in the Action at page 5. 

C. Differences 

IL Assembler does not teach or suggest "a type designated as an unknown type, wherein 
the unknown type indicates that an element of the representation is of a type that is not known" 
as recited by claim 1. Portions of IL Assembler pages 9-12 are reproduced below: 
Native Types 

wbert managed code culls unniVanagetJ methods or exposes managed fields to unmamaged code, it Is sometiities 
necessary Co provide specific information about how the- managed types should be marshaled to and from the 
unmanaged types. The unmanned types recognlzaule by oie common racisnrage runtime are referred to as naflVe, and 
they are feted In CorHdr.h in thfl enumeration CvrNatJveType. All constants In thll enumeration have names tfiat begin 
*rth NATiVejrfPEj* j for purposes of this discussion, i nave omitted 1 tnis part of title names or abbreviated it as ALT , 
The same constants are also listed In the .NET Framewcrt; class library in the enumerator 
System. Run&meJntieropSMYices. UnmnnagedType, 

Some of the native types are obsolete and are Ignored by the runHmo intBroperaMltty subsystem. But since thoHB 
native types are not retired altogether, ULAsm must have ways to denote them— and slr.cn ILASm demotes these types, 
I cannot help but list obsolete types along with other*, all of which you'll And In Table 7-6. 





Table Native Types Dctln 




Codta Constant Name .MET Framework llAsm Notation Comments 
Type Name 


okoi voiO' 


void 


Obsolete and thus should not be used; 
recognized by lLAsm but ignored by the 

runtime Interoperability SubSyoterni 


0*17 FIXEDSYSSmiM 


S ByVsfTStr And sysstrini 

[ <5i3H> J 


1 Fixed-system String of size <size> bytes; 
applicable. bo field marshaling only 


OkIS OR1ECTREF 




Obsolete 


0x19 RJHKHOVm 


lUaknown (tmicntmm 


lurtknowni interface pointer 


OxlA IDISPATCH 


IDispatch (dispatch 


IDispatch Interface pointier 


Qxl'B, STRUCT 


Struct struct 


C-style structure, for marshalnrug tine 


QKlC IT/TF 


Interface tnbeiface 


rnterfiiee pointer 
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variant Types 

Variant types are defined In the enumeration VARSNUMin the Wtypes.h ffle, whieh la distributed vtitti Microsoft: Visual 
studio. Not aill variant types are applicable a* ssfs array types, according to Wtypes.h, but ILAsm provides notation for 
all of ttiem nevertheless, as shown In Table 7-?, It might look Stran g, considering that variant typhis appear In IlAsm 
<only In the contest of safe .array specif] canon, but we stwukl not forget that one of luAsm's principal applications Is trie 
generation of test programs, which contain known, preprogrammed! errors. 





Trtle 7-7. Vari 


iant Types I 


JetfJncd (n the 


Runtime 


Code Constant Nome Applicable to Safe Array? ILAsm Ntf 


CxOQ 


VT_£HP1Y 


NO 






0x01 


VT_NULL 


Ho 




ml! 


0x02 


VT_I1 


Yes 




IntlG 


0X03 


LT_J<J 


Yes 




!nt$2 


0*Q4 


VTJM 


Yes 




fioaBZ 


0x05 


VT_RS 


Yes 




ffoat64 


OxC6 


vtjcy 


Yes 




currency 


0x07 


VT^DATE 


Yes 




date 




VT_B$TR 


Yes 




tKtr 


0X09 




Yes 




tdispateh 


OxQA 


VT_EMtOR 


Yes 




error 


OXOB 


VT_BQGL 


Yes 




tool 


OXCC 


VT_VAR1AKT 


Yes 




variant 


OkOD 




Yes 




lunknown 


OkC'E 


VT_DECIMAL 


Yes 




dedmaf 



What IL Assembler describes are the known interface types iUnknown and iDispatch. 

These are known interface types that are defined for Microsoft COM object interfaces: 

"The IUnknown interface lets clients get pointers to other interfaces on a given 
object through the Querylnterface method, and manage the existence of the 
object through the IUnknown ::AddRef and IUnknown: :Release methods. All 
other COM interfaces are inherited, directly or indirectly, from IUnknown. 
Therefore, the three methods in IUnknown are the first entries in the VTable for 
every interface." 

(Exhibit A, MSDN COM fundamentals: IUnknown(COM), available at: 
http://msdn.microsoft.com/en-us/library/rnsfj80509(VS,85).aspx). IL Assembler therefore 
teaches designating a type as a known type called "iUnknown," which designates the type as a 
well-known COM interface object type. Hence, IL Assembler does not teach or suggest 
designating a type as an unknown type, which "indicates that an element of the representation is 
of a type that is not known" as in the method of claim 1. 
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II. Claim 6. 

A. Claim 6 recites: 

A method of selectively retaining type information during compilation in a 
code segment written in a programming language, the method comprising: 

translating the code segment from the programming language to one or 
more representations of an intermediate language; 

for each representation, determining whether to retain type information for 
one or more elements of the representation; 

based on the determination, associating one or more elements of die 
representation with a type, designated as an unknown type, indicating the element 
can be of any type; and 

type-checking the one or more representations based on a rule set, wherein 
the rale set comprises rules for type-checking the type designated as the unknown 
type. 

B. U.S. Patent No. 6,560,774 to Gordon (Gordon) 

Gordon does not teach or suggest determining whether to retain type information and 
associating elements with an unknown type. The Examiner contends that the language of claim 
6, "determining whether to retain type information for one or more elements of the 
representation; based on the determination, associating one or more elements of the 
representation with a type, designated as an unknown type" is taught by Gordon, (Action, page 
6). 

C. Differences 

Gordon column 27 and FIG. 23 describes a "Virtual Execution System" (VES) that can 

skip verification, including "native-size primitive type checks" of precompiled native code that is 

fully trusted, (Gordon, col. 3, lines 7-8; col. 6, line 67-col. 7, line 5; col. 27, lines 12-33). 

Gordon teaches that the VES does not maintain type information to aid verification: 'the type of 

the arguments to any method in the code being verified are fixed This means that dynamic 

type information for arguments do not need to be maintained on a per-basic block basis." 

(Gordon, col. 7, lines 57-60) (emphasis added). Gordon further teaches that type information 

for primitive locals is "fixed" and that for non-primitives, type information must be maintained: 

[T]he type of primitive local variables, such as integers, floating points, 
etc., is fixed. If a variable is declared as being a primitive type, then it is not 
allowed to store a non-primitive type, such as an object reference, into it. In this 
manner, a single bit~"live" or "dead" for example-is sufficient to convey a 
primitive variable's state at any point. For non-primitive variables, however, 
complete type information must be maintained. 
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(Gordon, col. 7, line 66 through col. 8, line 6). This section does not describe "a type 
designated as an unknown type" nor does it disclose determining whether to retain type 
information for one or more elements of the representation, as recited by claim 6. 

Gordon, therefore, discloses a method of verification that either (1) does not maintain 
dynamic type information for arguments or (2) maintains complete type information as 
designated in the source code. This is not the same as the method of claim 6, which, after 
determining whether to retain type information for elements of the intermediate language 
representation, designates one or more elements "as an unknown type." 



Respectfully submitted, 



KLARQUIST SPARKMAN, LLP 




One World Trade Center, Suite 1600 
121 S.W. Salmon Street 
Portland, Oregon 97204 
Telephone; (503) 595-5300 
Facsimile: (503) 595-5301 
cc: Docketing 



Mark W. Wilson 
Registration No. 63,126 
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http://msdn.rrdcrosoftxoin/en-us/libraiy/ms680509(VS.85).aspx 
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COM 

I Unknown (COM) 

The [Unknown interface lets clients get pointers to other Interfaces on a given object through the Querylnterface method, and 
manage the existence of the object through the IUnknown: :AddRef and IUnknown:: Release methods. All other COM Interfaces 
are inherited, directly or Indirectly, from IUnknown. Therefore, the three methods In IUnknown are the first entries in the VTable 
for every interface. 

When to Implement 

You must Implement IUnknown as part of every interface. If you are using C++ multiple inheritance to implement multiple 
Interfaces, the various interfaces can share one implementation of IUnknown. If you are using nested classes to Implement 
multiple interfaces, you must Implement IUnknown once for each interface you Implement. 

When to Use 

Use IUnknown methods to switch between interfaces on an object, add references, and release objects. 
Methods in Viable Order 

P..?.?*?!*?. ' ' . Description 



■ Querylnterface [ http://msdn.microsoft.com/en-us/library/ms682521 : Returns pointers to supported 

CVS-85).aspx ] interfaces. 

AddRef [ http://msdn.micro5oft.com/en-us/library/ms691379(VS.a5).aspx ] \ Increments reference count. 

Release [ http://msdn,mlcrosofc.com/en-us/llbrary/ms6S23l7{vs.85).aspx ] j Decrements reference count. 

Requirements 

For an explanation of the requirement values, see Requirements (com) [ http://msdn.mlcrosoft.com/en-us/library/ms693432 
<V5.85).aspx ] . 

Windows NT/2000/XP: Requires Windows NT 3.1 or later. 
Windows 95/9S: Requires Windows 95 or later. 
Header: Declared in unknwn.h. 
Send comments abou t t his topic t o Mi crosoft. 
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